Mobile data transmission and data services are constantly making progress, wherein such services provide various communication services, such as voice, video, packet data, messaging, broadcast, etc. In recent years, Long Term Evolution LTE™ has been specified, which uses the Evolved Universal Terrestrial Radio Access Network E-UTRAN as radio communication architecture according to 3GPP specifications.
Furthermore, network virtualization is used in recent technologies, which splits the conventional networks into subsets to be used, operated and managed by different organizationally independent organizations. The use of network virtualization offers flexibility in the development of future network architectures.
The technical field according to the present invention is software defined networking (SDN, see ONF at https://www.opennetworking.org/index.php?option=com_content&view=category&layout=blog&id=41&Itemid=145&lang=en) for use e.g. in mobile telecommunication networks. Within the research of software defined networks SDN, a separation of the control plane and the user plane is discussed.
That is, in SDN, the system that makes decisions about where traffic is to be sent (control plane) is decoupled from the underlying systems that forward traffic to the selected destination (data plane).
Today, the eNB is an integrated monolithical entity which provides services to the 3GPP user equipment and mediates between the UE and the EPC (Evolved Packet Core). In order to provide the service, the eNB in general supports a control part and a user part. The user part of the eNB (eNB-U, eNB in user plane) in general forwards the payload to and from the user equipment towards/from the EPC. The control part of the eNB (eNB-C, eNB in control plane) in general covers the part which allows for the exchange of the signaling such that the UE and the EPC can request and grant particular services. In case of handover, there are the source and target eNBs involved, where source eNB denotes the eNB which the UE will leave, and where the target eNB is the one which receives the UE.
In the vertical control plane, a communication protocol is used, such as OpenFlow, FOrCES (Forwarding and Control Element Separation protocol), etc, for controlling the respective entities.
In case of OpenFlow, for example, the so called application rides on top of the OpenFlow controller (OFC, and is denoted as OFC+ to indicate that the controller is augmented with additional functionality).
In 3GPP specifications, the Intra E-UTRAN Access Mobility and S1 based handover (HO) is defined in TS 36.300 and TS 23.401. However, currently, the 3GPP specifications do not cover a solution in a SDN environment.
FIG. 1 shows an example of signaling in a case of an intra E-UTRAN handover of user equipment (UE) in the control plane, as shown in TS 36.300. A short explanation of the steps shown in FIG. 1 is given below. For details in this regard, reference is made to the description in TS 36.300.
In step 1, the source eNB (evolved NodeB) configures the UE measurement procedures according to the roaming and access restriction information.
In step 2, a MEASUREMENT REPORT is triggered and sent to the eNB.
In step 3, the source eNB makes decision based on MEASUREMENT REPORT and Radio Resource Management (RRM) information to hand off the UE.
In step 4, the source eNB issues a HANDOVER REQUEST message to the target eNB passing necessary information to prepare the HO at the target.
In step 5, an Admission Control may be performed by the target eNB.
In step 6, the target eNB prepares HO with L1/L2 and sends the HANDOVER REQUEST ACKNOWLEDGE to the source eNB.
In step 7, the source eNB sends the RRC message, i.e. RRCConnectionReconfiguration message including the mobilityControl Information, towards the UE.
In step 8, the source eNB sends the SN STATUS TRANSFER message to the target eNB to convey the uplink PDCP SN (packet data convergence protocol sequence number) receiver status and the downlink PDCP SN transmitter status of E-RABs (E-UTRAN Radio Access Bearer) for which PDCP status preservation applies.
After step 8, data forwarding is performed from the source eNB towards the target eNB.
In step 9, after receiving the RRCConnectionReconfiguration message including the mobilityControlInformation, UE performs synchronisation to target eNB and accesses the target cell via RACH (Random Access Channel).
In step 10, the target eNB responds with UL allocation and timing advance.
In step 11, When the UE has successfully accessed the target cell, the UE sends the RRCConnectionReconfigurationComplete message (C-RNTI, Cell Radio Network Temporary Identity) to confirm the handover, along with an uplink Buffer Status Report, whenever possible, to the target eNB to indicate that the handover procedure is completed for the UE.
In step 12, the target eNB sends a PATH SWITCH REQUEST message to MME (Mobility Management Entity) to inform that the UE has changed cell.
In step 13, the MME sends a MODIFY BEARER REQUEST message to the Serving Gateway (SGW).
In step 14, the Serving Gateway switches the downlink data path to the target side. The Serving gateway sends one or more “end marker” packets on the old path to the source eNB and then can release any U-plane/TNL (Transport Network Layer) resources towards the source eNB.
In step 15, the Serving Gateway sends a MODIFY BEARER RESPONSE message to MME.
In step 16, the MME confirms the PATH SWITCH REQUEST message with the PATH SWITCH REQUEST ACKNOWLEDGE message.
In step 17, by sending the UE CONTEXT RELEASE message, the target eNB informs success of HO to source eNB and triggers the release of resources by the source eNB. The target eNB sends this message after the PATH SWITCH REQUEST ACKNOWLEDGE message is received from the MME.
In step 18, upon reception of the UE CONTEXT RELEASE message, the source eNB can release radio and C-plane related resources associated to the UE context. Any ongoing data forwarding may continue.
According to FIG. 1, the Source eNB forwards the user plane data and the SN Status Transfer to the target eNB at least after the receipt of the handover request ack (cf. steps 6 and 8 in FIG. 1).
Further, according to FIG. 1, the target eNB forwards the user plane data to UE and the SGW at least after the receipt of the SN Status Transfer and the RRCConnectionReconfigurationComplete message (cf. steps 8 and/or 9 to 11 of FIG. 1).
However in the SDN environment, the OpenFlow protocol and/or the Forces protocol are not capable to support these features today.
That is, regarding the source eNB, in the SDN/OPENFLOW/Forces environment the source eNB Controller (or any other RAN (Radio Access Network) controller) currently cannot send the DL COUNT value and the UL COUNT value available at the eNB-U of the source eNB to the target eNB-C.
Further, regarding the target eNB, in the SDN/OPENFLOW/Forces environment the target eNB Controller (or any other RAN controller) currently cannot send the DL COUNT value and the UL COUNT value available at the eNB-C to the target eNB-U.
The DL and UL count is needed at the target eNB-U for correct synchronization of the packets.
Further, it is noted that according to current OpenFlow (OF) specifications, there are only three message which can be sent to the OF controller (i.e., Packet IN, Flow removed, Port status) but which per definition do not serve the needs for Handover.
For facilitating the understanding of the present description, the following is noted:                IP packets from the eNB towards the UE are sent via the PDCP protocol, and IP packets from the eNB towards the EPC (Evolved Packet Core) are sent via the GTP-U (GPRS Tunneling Protocol User Plane) protocol;        The PDCP PDU (Packet Data Unit) Number being carried over GTP-U (transferring the SN) is defined in chapter 5.2.2.2 of TS 29281;        The PDCP SN for the PDCP protocol is defined in chapter 6.2.4 of TS 36323;        The (UL and DL) COUNT Value transported via the SN Status transfer on the X2 Interface is defined in chapter 9.1.1.4 and chapter 9.2.15 of TS 36423.        The (UL and DL) COUNT Value transported via the MME/eNB Status transfer on the S1 Interface is defined in TS 36413.        